home *** CD-ROM | disk | FTP | other *** search
/ Visual Basic Source Code / Visual Basic Source Code.iso / vbsource / project / knownbug.txt < prev    next >
Text File  |  1999-05-30  |  9KB  |  240 lines
  1. Known bugs and limitations in Project Analyzer 5.1
  2. ==================================================
  3.  
  4. This file includes the known bugs and limitations in Project Analyzer.
  5. Project Analyzer is of high quality and these bugs occur mostly only in
  6. special cases. 
  7.  
  8. Some of these limitations are on a to-do list, some can't be fixed at
  9. all. Those are disadvantages in the static (design-time) analysis method
  10. that Project Analyzer uses. 
  11.  
  12. Please report any new bugs to vbshop@aivosto.com. If you can, attach a
  13. short code file or test project to facilitate debugging. Many bugs are
  14. next to impossible to fix without sample code.
  15.  
  16.  
  17.  
  18. ================
  19. For best results
  20. ================
  21.  
  22. - Always declare your local variables (use Option Explicit)
  23. - Always save your files as text (VB 3.0)
  24. - Use MS Word as your RTF editor
  25. - Wait for the analysis to end completely (it has 2 phases)
  26. - Use correct VB syntax. Project Analyzer relies on the correctness of
  27.   your code. If you analyze a project that VB cannot run, you may get
  28.   funny results.
  29. - Use good coding practice. Put only one statement on one code line. 
  30.  
  31.  
  32. ===========
  33. Limitations
  34. ===========
  35.  
  36. - Project Analyzer has no known practical limit to the size of projects 
  37.   it can handle. It has been successfully used with projects that are 
  38.   several MB in size, and have over 100,000 lines of code.
  39. - The size of variable, constant and procedure names is restricted to 64
  40.   characters to save some memory. Longer names are truncated.
  41. - Super Project Analyzer can handle a group of max 50 projects at once
  42.  
  43. - There are limits to the number of references in one procedure and
  44.   module. There is no hard limit for the total number of references.
  45.  
  46.   Procedure reference limit:         Max
  47.   From a procedure to other procs    100 calls / procedure  Fan-out
  48.  
  49.   Module reference limit:            Max
  50.   From a module to other modules     100 refs / module      Fan-out
  51.   To a module from other modules     200 refs / module      Fan-in
  52.  
  53.   If you are concerned if your LARGE project has met one of these
  54.   limits, see the Metrics window for structural fan-outs = 100 or 
  55.   structural fan-ins = 200.
  56.  
  57.   Variable, constant, Type and Enum references are not limited.
  58.  
  59.  
  60. ==================
  61. Known misbehaviour
  62. ==================
  63.  
  64. - If you get "Automation error" or "Unexpected error" in Project Graph, 
  65.   make sure lgraph.ocx is in the same directory as project.exe, and 
  66.   re-register it with regsvr32.exe (comes on the VB CD).
  67. - Long procedural call tree reports (All procedures) can hang the computer
  68. - In the following code
  69.   For x = 1 to 10 : Debug.Print "Hello world" : Next
  70.   X is reported as Used only in assignment, even if it really is
  71.   both assigned and referenced by the For...Next statement.
  72.  
  73. - If an array defined as New ObjType is later ReDim'd, the ReDim doesn't
  74.   count as an assignment but a reference, even if the ReDim creates new
  75.   objects in the array.
  76. - ReDim statements without the Preserve keyword may cause Project
  77.   Analyzer to think there is an extra local array variable. Example:
  78.  
  79.   ' (declarations)
  80.   Dim MyArray() As Integer
  81.  
  82.   Sub MyProcedure()
  83.   ReDim MyArray(100) As Integer
  84.  
  85.   Project Analyzer may think MyArray is a new array if 
  86.   1) the original Dim is located in the (declarations) section of 
  87.      another module, AND
  88.   2) the module with Dim comes after the module with ReDim in your MAK
  89.      or VBP file.
  90.  
  91.   The cure is to swap the order of the modules in MAK/VBP, or use 
  92.   ReDim Preserve, or mark the ReDim statement with '$ USED (see 
  93.   project.hlp for Comment directives). There is no way in the current 
  94.   2-phase analysis architecture of Project Analyzer to fix this problem.
  95.  
  96. - Problems arise with long object.property.property chains for objects 
  97.   that have object-type properties. Example:
  98.   MyObject.MyChildObject.Prop = 2
  99.   (where property MyChildObject is a class object)
  100.  
  101.   This should be Property Get MyChildObject and Let Prop.
  102.  
  103.   Cause of problem: Choosing between Set/Let/Get is done according to the
  104.   last property in the chain. In the above case, it's a Let because of the
  105.   assignment to Prop. 
  106.  
  107.   Result: This leads the analyzer to think it's a Let to MyChildObject 
  108.   too, although it should be a Get. Since there is no Let for Object
  109.   property (but Set instead), the analyzer ignores these references.
  110.  
  111.  
  112. - Given the following code in MyClass:
  113.   private sub a()
  114.     dim u as new MyClass
  115.     u.b
  116.   end sub
  117.  
  118.   public sub b()
  119.   end sub
  120.  
  121.   MyClass.b is reported as "needless global" despite that it couldn't be 
  122.   declared private.
  123. - Super Project Analyzer treats two files in different directories but with 
  124.   the same filename as one file. 
  125.  
  126.  
  127. Name shadowing bugs
  128. -------------------
  129.  
  130. - In the hypertext window, letters in DefType statements may be 
  131.   mistaken for one-letter variable names
  132. - In the hypertext window, if you have two different definitions with the
  133.   same name (e.g. Form1.MyVar and Form2.MyVar), the program may
  134.   highlight the both in red when only the other one should be
  135.   highlighted. This bug has no effect on the real analysis. 
  136. - If a local var/const has the same name as the procedure it's in, the
  137.   procedure name will be mistaken for the var/const name in the
  138.   Hypertext window and Project Printer. This has no effect on the
  139.   analysis, though.
  140. - If a module has the same name as a procedure or a variable/constant, 
  141.   this can result in erroneous references not going to the module name.
  142.   No problem with Types and Enums (can't have same name).
  143.  
  144.  
  145.  
  146. ===============================
  147. Deficiencies in VB 3.0 features
  148. ===============================
  149.  
  150. - The Summary report shows somewhat distorted figures for 
  151.   1. Global Name Table: Type definitions and DLLs declarations are
  152.      not calculated correctly.
  153.   2. Global Symbol Table: type definitions are excluded, and everything 
  154.      else is assumed to take 10 bytes of memory.
  155.   Use freeware VB Space (by Gregg Irwin) for more exact calculations.
  156.   Available at http://www.aivosto.com/vblinks.html
  157. - Can't analyze files saved as binary. Save as text instead.
  158.  
  159.  
  160. =======================
  161. Unsupported VB features
  162. =======================
  163.  
  164. - Line labels. If you use them, you may get incomplete results on those
  165.   lines that have a label. Line numbers are supported. 
  166. - The [] syntax is not fully supported. For example, in the below code,
  167.   Dim X As Integer
  168.   Print [X]
  169.   the reference to variable X is not detected because of the [] syntax.
  170. - Line continuation character "_" is supported by the analysis, but not 
  171.   by VB Browser or Project Printer. This has no other known effect 
  172.   than incorrectly reporting calls to Property Let/Set as Property Get. 
  173.   This happens if the "=" is not on the first line, like this:
  174.       MyProperty _
  175.          = Value
  176.  
  177.  
  178. ===============================
  179. Unsupported VB 5.0/6.0 features
  180. ===============================
  181.  
  182. - Controls are not detected on ActiveX Designer Forms (.dsr/.dsx files)
  183.  
  184.  
  185. ===================
  186. Unsolvable problems
  187. ===================
  188.  
  189. The following problems cannot be solved by design-time source code
  190. analysis. This is because they would need run-time information.
  191.  
  192. - Late-bound references. Example:
  193.   Forms(2).DoSomething 
  194.  
  195.   Project Analyzer can't know which form the call goes to, because 
  196.   Forms(2) may be of any of your forms. This applies to all object
  197.   references that are of a general type (e.g. As Form, As Object) 
  198.   and not a specific type (As MyForm, As MyObject).
  199.  
  200. - Variants are classified as non-object variables, even if they contain
  201.   an object, because there is no way to detect this at design-time.
  202.   This may lead to minor flaws, like with the below code:
  203.  
  204.    Dim v as Variant
  205.    Set v = Form1
  206.    v.Caption = "This is my form"
  207.      
  208.   Here the last statement is considered an assignment to v, although,
  209.   strictly speaking, it's a reference to v (and assignment to Caption). 
  210.   Fortunately, this doesn't do much harm. If v was defined as 
  211.   Dim v as Form (instead of Variant), the reference would be detected
  212.   just OK.
  213.  
  214. - Inherits